Всем привет,

сегодня я сдавал 3-е задание Волканову и я с ним долго резвился на разные темы, в итоге

1) Моё решение вы можете уже найти рядом
2) Он просил передать вам, что делать так, как сделал я - ещё дополнительно заведя таймер, для того, чтобы связать время с выполнением задач на процессорах, и чтобы не было лишнего увеличения времени - нельзя. Скажу вам, что это не беда, ибо можно легко заменить это дело глобальными переменными.
3) Для тех, кто не уловил сразу фишку с каналами (channels)
    1) их уместнее было бы называть флагами, и у них есть 3 режима и 2 способа использования
    2) flagName! - поднимает флаг, flagName? - ждёт, пока кто-нибудь поднимет его
    3) обычный флаг достаточно поднять один раз, чтобы потом на нём никто не останавливался
    4) urgent флаг - нужно поднимать каждый раз заново
    5) broadcast флаг - сами догадайтесь
    6) когда 2 процесса - один, который ждёт поднятия флага, другой - поднимает его, то при поднятии, второй процесс не медленно передвигается, делая шаг, причём update на соответствующих рёбрах графа срабатывают сначало для того, кто поднял флаг, а потом для того, кто его ждал (в случае с broadcast - смотрится среди тех, кто ждал, в каком порядке были запущенны процессы в system команде)
Каналы полностью заменяемы глобальными переменными, но с ними частенько удобнее
Из каналов можно построить 2 концепции: семафоры (двоичные) и mutex (хотя разница конечно не большая) )
У меня вы найдёте концепцию mutex, но что делать - ваше дело.

3) у меня так сделано, что есть broadcast флаг отвечающих за тик, для всех процессоров, логично, что чем больше процессоров сделает тик, тем быстрее можно выполнить все работы, так что полезно сделать так же, и тогда в verifyta можно будет просто указать - выдать в конце самую короткую трассу, и тогда вы сразу вычислите минимальное время для расписания.
(стоит подумать о разнице между самым быстрым выполнением задач и самым малым простоем процессоров, и как это отразится на модели )) (по мне - так никак, вопрос лишь в том, что вы будете писать в своём ответе - нужно будет указать на то или другое))

другой способ выяснить лучшее расписание - описан у него в кратце и чуть подробнее в моём файле отчёта - там достаточно, чтобы вы поняли, как это делать и могли сделать свой выбор

4) Он дал (по крайней мере мне) 3 процессора и 9 задач, проблема в том, что просчёт моей модели by verifyta занимал больше 5 гигов памяти, которые я мог выделить и после выедания этих гигов, спустя эдак 15 минут - verifyta падает.
Он вам вскоре должен разослать поправки к заданию, где уменьшит количество чего-нибудь (мне он сократил количество процессоров до 2-х)

Правда частично я - лопух, потому что можно было бы улучшить результат, например слив первые 3 шага в моей модели задачи в одну ветвь, но погоды это не делает, потому что 3x9 - это просто эпичное количество состояний.
(но более компактная модель сохранена мною как 3_3u)

Вот так, как-то.